參賽前言

嗨，大家好，隔了一年又再次踏上鐵人賽。回顧 2023 年，我曾提到許多在地化功能需要更多台灣廠商與使用者的努力。今年，我想更進一步，從觀察走向架構，由AI來實作，嘗試將在地需求化為具體的設計與模組。

這次參賽的核心想法是：能否打造一個真正符合台灣在地需求的「社群版會計模組」。透過這 30 天的紀錄，我會分享過程中的嘗試、挑戰與收穫，也期待和更多人交流，讓 ODOO 在台灣的應用能走得更深、更遠。

模組的開發像「產品」，需要設計、維護，甚至能商業化；而文章則像「地圖」，標示經驗，幫助後來者少走冤枉路。AI 在這過程中扮演陪練角色，協助快速試錯，但真正的價值仍在於開發者如何設計結構、拆解問題，並將經驗沉澱成知識。

這 30 天的系列文章，不是要宣稱「最完美的模組」，而是展示一條路徑：在地化 ERP 的挑戰下，如何透過人與 AI 的協作，把想法一步步轉化為原型。鐵人賽結束，但留下的是一份知識地圖，成為社群未來持續前進的養分。

架構

後續的文章會使用以下架構
探索
可能是現況內容與開發原因，或一些前提介紹，那目的是讓讀者知道為何而作。
架構
可能是模組功能的特色，或說明架構的原因。
實作
透過一些資料的維護，在ODOO實作後的畫面呈現。
小補充
分享製作每個報表或維護作業的實務經驗的補充。

實作

後續比較多是一些案例驅動的分享，分享技術架構原則，說明如下:

在開發台灣會計模組的過程中，就像在蓋一座大樓，深刻體會到「打好地基」的重要性！第三方軟體雖然提供了豐富的功能，就像現成的建材一樣，但這些建材的規格往往不一致，不同的開發者就像不同的工人，採用不同的施工方法，這使得後續的裝修和擴建變得困難重重。因此，筆者決定自己設計一套建築標準，就像制定自己的施工規範一樣，讓整個系統的程式碼結構更加清晰、一致，就像每層樓的設計都有統一的風格！

架構設計原則建立在三個核心概念上：

• 模組化（就像積木一樣可以自由組合）
• 可重用（就像積木可以重複使用）
• 易維護（就像積木容易清潔）

透過標準化的程式碼結構，確保每個功能模組都遵循相同的開發規範，就像每個房間都按照統一的設計圖來裝修。在實作過程中，特別注重程式碼的邏輯順序安排，就像裝修時要先鋪地板再貼壁紙一樣，並為每個關鍵步驟添加詳細的備註說明，就像裝修說明書一樣清楚。同時，筆者習慣請AI建立完整的README文件來記錄架構設計思路與技術實現細節，後續在維護時先查看文件就可以比較快進入狀況！

最重要的是，我發現架構設計就像裝修房子一樣，是一個持續優化的過程！ 在實際開發中，當初的設計理念往往需要根據實作經驗進行調整，就像裝修時發現某些設計不太實用需要改進一樣。因此，採用了迭代式的開發方法，在每次實作完成後都會回頭檢視架構設計，進行必要的優化與重構。這樣的過程雖然耗時，但能夠確保最終的系統架構更符合期待，就像裝修好的房子既美觀又實用，為後續的維護與再開發奠定堅實的基礎！以下是標準參考:

統一技術標準

• 開發規範：所有模組遵循相同的開發標準
• 命名規範：統一的命名規則和編碼標準
• 錯誤處理：統一的錯誤處理和日誌記錄機制

小補充 - AI工具選擇

筆者採用單月訂閱的方式，在製作過程中主要使用ChatGPT模型進行開發，也曾經嘗試過Claude透過CLI進行溝通，最後選擇了Cursor整合IDE作為主要開發工具。在探索的過程中，發現每套AI模型都有其獨特的特性，建議大家挑選自己覺得語意理解順暢、能順利執行的AI模型即可。畢竟一年的時間變化實在太快，探索過程可以多方嘗試，找到最適合自己的AI夥伴。

在選擇AI時，會優先挑選能夠理解程式架構、且前後文表現不錯、能快速適應的AI模型。當AI在製作過程能夠理解程式架構時，就不需要每次都進行相同模式的溝通，這點特別重要！尤其是近期對話不能太長會被截斷，如果每次都重新開始，就等於要跟一個新的AI重新說明架構，非常耗時。因此，會儘量控制在一個對話內完成架構設計後，再逐步進行調修和優化。

小結

近期看到李昆謀在社群上的分享， 聊聊Vibe Coding所帶來的感受，其中文章中提到：

　觀念在手，執行交給 AI 就行了
　有些經驗會變成包袱，有些經驗才會變成油礦，加上 AI 會井噴

剛好切中我這陣子的開發過程，很多時間我都下完指令後，就去喝茶、整理環境、走走看看過程中，就完成了一個功能，現在要動手做一個應用，都會先跟AI討論設計，就像在規劃模型的藍圖一樣，來來回回對話中，AI會自己列出搭建步驟，然後一步步完成，我就坐在觀眾席看AI照藍圖施工，原來還是很喜歡這種創造的感覺，一直以來都是！

我想井噴不是偶然，而是累積的必然，接下來章節，就嘗試讓AI點燃看看有什麼樣的火花。